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REMARKS 



Claims 2-24 had been indicated to be allowable in the Office action mailed 
02/03/2003. Accordingly, applicants had responded to that Office action by canceling 
claim 1 and rewriting in independent form those claims that had directly depended from 
claim 1 . Applicants had not intended by that action to have acceded to the validity of the 
rejection of claim 1 set forth in the Office action of 02/03/2003. Indeed, applicants had 
intended to file a continuation application in which claim 1 would have been presented. 

Claims 2-24 that were previously deemed to be directed to allowable subject 
matter were then rejected in the Office action of 09/02/2003. Applicants believe that the 
subject matter defined in all of the originally presented claims — including claim 1 — 
distinguish the invention from the cited prior art. The Rules of Practice do not allow 
canceled claim 1 to be re-introduced with the same claim number. Rather than re- 
introduce a new claim similar to canceled claim 1 with a new claim number and then re- 
amend claims that had depended from claim 1, applicants have chosen to cancel claims 
2-24 and to present new claims 25-76 which are directed, in part, to the inventive subject 
matter that had been defined in claims 2-24, albeit using somewhat different 
terminology. 



Objections and Rejection under 35 USC 112 



Various ones of claims 2-24 were objected to due to informalities or rejected as 
being indefinite under 35 USC 112. Since claims 2-24 have all been canceled, the 
objections and Section 112 rejection have been rendered moot. The examiner's careful 
reading of claims 2-24 is appreciated and her remarks vis-a-vis claims 2-24 were 
carefully taken into account when drafting new claims 25-76. It is believed that none of 
the newly added claims are informal or indefinite. 
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Rejections under 35 USC 102-103 

Claims 2-24 were rejected as unpatentable over Sengodan or Sengodan in 
combination with Ash and/or Hin. Since these claims have all been canceled, those 
rejections have been rendered moot. However, it is noted for the record that applicants 
regard those claims, as well as previously canceled claim 1, as distinguishing the 
invention from the cited prior art, for at least some of the reasons set forth hereinbelow 
relative to new claims 25-76. 

In the following sections, various aspects of applicants' invention as set forth in 
various ones of the claims are discussed. It is respectfully submitted that even if it 
would have been obvious to combine the teachings of the cited prior art references in 
some way or another, none of the cited references, taken singly or in combination, show 
or suggest these aspects of the invention and applicants' claims do not read on that 
which the references, or combinations of them, do disclose. 

Reserving of Resources 

Independent claims 25, 32, 68 and 74 — like various ones of canceled claims 1- 
24 — call for "reserving. . .packet network resources." 

The Office action points to the operation in Sengodan, wherein an Admission 
Request message "carrying the bandwidth the endpoint requires for the duration of the 
call" as corresponding to the reserving function called for in applicants' claims. 

Applicants respectfully disagree. 

When resources are reserved, this means that they are guaranteed to be available 
for the packets to follow. Even when giving the wording "reserving" its broadest 
reasonable ordinary meaning, the function of "reserving resources" necessarily involves 
such a guarantee or a setting aside of the resources. The following definition of the verb 
"reserve" appears in The Random House Dictionary of the English Language, 1966 
edition: 
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1. to keep back or save for future use, disposal, treatment, etc. 2. to retain or 
secure by express stipulation. 3. to set apart for a particular use, purpose, 
service, etc.:... 

By contrast, no actual reserving of resources is carried out in Sengodan. Rather, 
the ARQ message in Sengodan is an indication as to how much bandwidth the endpoint 
would Hke to have. It is not a reservation of resources and, indeed, there is nothing in 
Sengodan to suggest that a device that requested a certain amount of bandwidth is going 
to have resources reserved for it so as to guarantee that the call will actually be provided 
with that bandwidth throughout the call. 

Indeed, as is well known, the H.323 protocol that is used in Sengodan is one that 
sits "on top of common network architectures. See, for example, the H.323 primer 
(copy attached) appearing at http://www.packetizer.com/iptel/h323/Dapers/primer under 
the heading "Network Independence." This means that any allocation of resources on the 
network that is actually going to carry the call is not any concern of H.323 but, rather, of 
the underlying network. 

Moreover, independent claims 25, 32, 68 and 74 all recite that what is being 
reserved are resources of two or more packet networks and that those two networks have 
different reservation policies. Sengodan does disclose the transmission of signals, e.g., 
packets, over different networks. However, since Sengodan does not disclose any 
resource reservation , that reference certainly cannot be said to disclose that two packet 
networks have different resource reservation policies . 

Moreover, various claims set forth limitations as to the manner in which 
resources are reserved. Since as discussed above the prior art does not disclose the 
reserving of resources, it certainly cannot be said to disclose, for example, 

a) reserving resources in particular kinds of networks, such as an access 
network, backbone network, television coaxial cable network, and packet 
telephony service provider network (e.g., claims 26, 27, 32, 33, 38, 40, 43, 45, 
52, 54, 56, 58, 59, 62, 68, 69, and 73); 

b) indicating any kind of limits for reserved resources (e.g., claims 29 and 31); 

c) reserving resources on a per-call or multiple-call basis (e.g., claims 34, 35 
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and 49 ); 

d) reserving bi-directional or uni-directional capacity (e.g., claims 36, 37, 46, 47, 
and 66); 

e) reserving resources in a network based on a selected one of a plurality of 
reservation policies for that network (e.g., claims 44, 57, 70 and 75); 

f) reserving a constant-bit-rate channel in one network and other than a constant- 
bit-rate channel in another network (e.g., claims 61 and 72). 

Separate Reservation Policies for Interconnected Packet Networks 

Each of the claims in the application makes reference to at least two networks, 
both of which are packet networks. Applicants are not aware of any prior art showing or 
suggesting that when a call is made using the resources of more than one packet 
network, that the networks could have different resource reservation policies and that the 
call could nonetheless be set up by what is essentially a two-step process in which 
resources for each packet network are reserved separately. 

Certainly this idea is neither shown nor suggested in any of the cited prior art. 

Reserving of Resources in Response to Reserve Messages 

A further distinguishing aspect of applicants' invention relates to the fact that in 
particular embodiments of the invention, the resource reservation in, for example, an 
access packet network and a backbone packet network according to their own 
reservation policies is carried out in response to a single reserve message received from 
a calling or from a called party. See, for example, claims 38, 42, 44 and 55. Even if the 
recitations in applicants' claims directed to reserving resources in two or more packet 
networks according to their own reservation policies could be said to read on prior art 
arrangements, the prior art certainly does not show or suggest doing any such reservation 
in response to a single reserve message received from a party. 
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A yet further distinguishing aspect of the invention relates to the fact that in 
particular embodiments of the invention, a second reserve message — specifically a 
backbone reserve message — is sent into the backbone packet network in response to the 
reserve message received from the calling party. See, for example, claims 39 and 44. 
Nothing in the cited prior art shows or suggests this aspect of the invention. 

And certainly, then, the prior art cannot be said to show or suggest the aspect of 
the invention claimed in, for example, claim 42. That claim, together with its antecedent 
claims 36-38, recites that a) in response to a calling party's reserve message, resources 
are reserved in & first access packet network and a backbone network and that b) in 
response to a called party's reserve message, resources are reserved in a second access 
packet network and the backbone network, where the reservation policy for the 
backbone network is different from that of the access packet networks. 

A Single Device Carries Out the Claimed Method 

A further distinguishing aspect of applicants' invention relates to the fact that in 
particular embodiments of the invention, the resource reservation in at least two 
networks is carried out by a single device and, in particular embodiments, that particular 
device is a network edge device that may be a bridge or a router. See, for example, 
claims 51, 58, 60, 68, 71, 74 and 76. 



Other Distinguishing Aspects of the Invention 

Various other limitations in the claims may provide yet further bases on which it 
can be found that applicants' claims distinguish over the prior art. Inasmuch as the 
foregoing is believed to establish the patentability of each of the claims in the 
application, such further points of distinction need not be raised at this time. Thus while 
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focusing herein on particular distinguishing aspects of the invention, Applicants may 
choose in the future to point to yet other bases on which various claims distinguish over 
the prior art. 

In view of the foregoing, it is believed that all of the claims in the application are 
in condition for allowance. Reconsideration and passage of the application to issue are 
earnestly solicited. 



Respectfully submitted, 
Charles R. Kalmanek, Jr. et al 




Reg. No. 26,585 
(732) 249-0900 



Law Office of Ronald D. Slusky 
P.O. Box 4378 

Highland Park, New Jersey 08904-4378 
Date: /A^Z/ 




17 



Packetizer. 



Easy Video Conferencing Vide o Conferencing 

Uses Std USB Web Cams & Browser Fast, Easy Install - Providing impactful solutions for all conferench 
Free Trial & budgets. 

Ads 

A Primer on the H.323 Series Standard 

Version 2.0 



The H.323 standard provides a foundation for audio, video, and data communications across IP-based 
networks, including the Internet. By complying to H.323, multimedia products and applications from 
multiple vendors can interoperate, allowing users to communicate without concern for compatibility. 
H.323 will be the keystone for LAN-based products for consumer, business, entertainment, and 
professional applications. 

H.323 is an umbrella recommendation from the International Telecommunications Union (ITU) that sets 
standards for multimedia communications over Local Area Networks (LANs) that do not provide a 
guaranteed Quality of Service (QoS). These networks dominate today's corporate desktops and include 
packet-switched TCP/IP and IPX over Ethernet, Fast Ethernet and Token Ring network technologies. 
Therefore, the H.323 standards are important building blocks for a broad new range of collaborative, 
LAN-based applications for multimedia communications. 

The H.323 specification was approved in 1996 by the ITU's Study Group 16. Version 2 was approved in 
January 1998. The standard is broad in scope and includes both stand-alone devices and embedded 
personal computer technology as well as point-to-point and multipoint conferences. H.323 also 
addresses call control, multimedia management, and bandwidth management as well as interfaces 
between LANs and other networks. 

H.323 is part of a larger series of communications standards that enable videoconferencing across a 
range of networks. Known as H.32X, this series includes H.320 and H.324, which address ISDN and 
PSTN communications, respectively. This primer provides an overview of the H.323 standard, its 
benefits, architecture, and applications. 

Why H.323 is Important 

The H.323 Recommendation is comprehensive, yet flexible, and can be applied to voice-only handsets 
and full multimedia video-conferencing stations, among others. H.323 applications are set to grow into 
the mainstream market for several reasons. 

■ H.323 sets multimedia standards for the existing infrastructure (i.e. IP-based networks). Designed to compensate for 
the effect of highly variable LAN latency, H.323 allows customers to use multimedia applications without changing 
their network infrastructure. 

■ IP LANs are becoming more powerful. Ethernet bandwidth is migrating from 10 Mbps to 100 Mbps, and Gigabit 
Ethernet is making headway into the market. 

■ By providing device-to-device, application-to-application, and vendor-to-vendor interoperability, H.323 allows 
customer products to interoperate with other H.323-compliant products. 

■ PCs are becoming more powerful multimedia platforms due to faster processors, enhanced instruction sets, and 
powerful multimedia accelerator chips. 




■ .H.323 provides standards for interoperability between LANs and other networks. 

■ Network loading can be managed. With H.323, the network manager can restrict the amount of network bandwidth 
available for conferencing. Multicast support also reduces bandwidth requirements. 

■ H.323 has the support of many computing and communications companies and organizations, including Intel, 
Microsoft, Cisco, and IBM. The efforts of these companies will generate a higher level of awareness in the market. 

Key Benefits ofH323 

Codec Standards 

H.323 establishes standards for compression and decompression of audio and video data streams, 
ensuring that equipment from different vendors will have some area of common support. 

Interoperability 

Users want to conference without worrying about compatibility at the receiving point. Besides ensuring 
that the receiver can decompress the information, H.323 establishes methods for receiving clients to 
communicate capabilities to the sender. The standard also establishes common call setup and control 
protocols. 

Network Independence 

H.323 is designed to run on top of common network architectures. As network technology evolves, and 
as bandwidth-management techniques improve, H.323-based solutions will be able to take advantage of 
those enhanced capabilities. 

Platform and Application Independence 

H.323 is not tied to any hardware or operating system. H.323-compliant platforms will be available in 
many sizes and shapes, including video-enabled personal computers, dedicated platforms, IP-enabled 
telephone handsets, cable TV set-top boxes and turnkey boxes. 

Multipoint Support 

Although H.323 can support conferences of three or more endpoints without requiring a specialized 
multipoint control unit, MCU's provide a more powerful and flexible architecture for hosting multipoint 
conferences. Multipoint capabilities can be included in other components of an H.323 system. 

Bandwidth Management 

Video and audio traffic is bandwidth-intensive and could clog the corporate network. H.323 addresses 
this issue by providing bandwidth management. Network managers can limit the number of 
simultaneous H.323 connections within their network or the amount of bandwidth available to H.323 
applications. These limits ensure that critical traffic will not be disrupted. 

Multicast Support 

H.323 supports multicast transport in multipoint conferences. Multicast sends a single packet to a subset 
of destinations on the network without replication. In contrast, unicast sends multiple point-to-point 
transmissions, while broadcast sends to all destinations. In unicast or broadcast, the network is used 
inefficiently as packets are replicated throughout the network. Multicast transmission uses bandwidth 
more efficiently since all stations in the multicast group read a single data stream. 



Flexibility 



An H.323 conference can include endpoints with different capabilities. For example, a terminal with 
audio-only capabilities can participate in a conference with terminals that have video and/or data 
capabilities. Furthermore, an H.323 multimedia terminal can share the data portion of a video conference 
with a T.120 data-only terminal, while sharing voice, video, and data with other H.323 terminals. 

Inter-Network Conferencing 

Many users want to conference from a LAN to a remote site. For example, H.323 establishes a means of 
linking LAN-based desktop systems with ISDN-based group systems. H.323 uses common codec 
technology from different videoconferencing standards to minimize transcoding delays and to provide 
optimum performance. 



Architectural Overview 
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Click for larger version 



The H.323 Recommendation covers the technical requirements for audio and video communications 
services in LANs that do not provide a guaranteed Quality of Service (QoS). H.323 references the T.120 
specification for data conferencing and enables conferences which include a data capability. The scope 
of H.323 does not include the LAN itself or the transport layer that may be used to connect various 
LANs. Only elements needed for interaction with the Switched Circuit Network (SCN) are within the 
scope of H.323. Figure 1 outlines an H.323 system and its components. 

H.323 defines four major components for a network-based communications system: Terminals, 
Gateways, Gatekeepers, and Multipoint Control Units. 

Terminals 
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Terminals are the client endpoints on the LAN that provide real-time, two-way communications. Figure 



2 describes the terminal components. All terminals must support voice communications; video and data 
are optional. H.323 specifies the modes of operation required for different audio, video, and/or data 
terminals to work together. It is the dominant standard of the next generation of Internet phones, audio 
conferencing terminals, and video conferencing technologies. 

All H.323 terminals must also support H.245, which is used to negotiate channel usage and capabilities. 
Three other components are required: Q.931 for call signaling and call setup, a component called 
Registration/ Admission/Status (RAS), which is a protocol used to communicate with a Gatekeeper; and 
support for RTP/RTCP for sequencing audio and video packets. 

Optional components in an H.323 terminal are video codecs, T.120 data conferencing protocols, and 
MCU capabilities (described further below). 

Gateways 
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The Gateway is an optional element in an H.323 conference. Gateways provide many services, the most 
common being a translation function between H.323 conferencing endpoints and other terminal types. 
This function includes translation between transmission formats (i.e. H.225.0 to H.221) and between 
communications procedures (i.e. H.245 to H.242). In addition, the Gateway also translates between 
audio and video codecs and performs call setup and clearing on both the LAN side and the switched- 
circuit network side. Figure 3 shows an H.323/PSTN Gateway. 

In general, the purpose of the Gateway is to reflect the characteristics of a LAN endpoint to an SCN 
endpoint and vice versa. The primary applications of Gateways are likely to be: 

■ Establishing links with analog PSTN terminals. 

■ Establishing links with remote H.320-compliant terminals over ISDN-based switched-circuit networks. 

■ Establishing links with remote H.324-compliant terminals over PSTN networks 

Gateways are not required if connections to other networks are not needed, since endpoints may directly 
communicate with other endpoints on the same LAN. Terminals communicate with Gateways using the 
H.245 and Q.931 protocols. 

With the appropriate transcoders, H.323 Gateways may support terminals that comply with H.310, 
H.321,H.322, andV.70. 

Many Gateway functions are left to the designer. For example, the actual number of H.323 terminals that 
can communicate through the Gateway is not subject to standardization. Similarly, the number of SCN 
connections, the number of simultaneous independent conferences supported, the audio/video/data 
conversion functions, and inclusion of multipoint functions are left to the manufacturer. By 
incorporating Gateway technology into the H.323 specification, the ITU has positioned H.323 as the 
glue that holds the world of standards-based conferencing endpoints together. 

Gatekeepers 

A Gatekeeper is the most important component of an H.323 enabled network. It acts as the central point 
for all calls within its zone and provides call control services to registered endpoints. In many ways, an 



H.323 gatekeeper acts as a virtual switch. 



figure 4 
Click for larger version 

Gatekeepers perform two important call control functions. The first is address translation from LAN 
aliases for terminals and gateways to IP or IPX addresses, as defined in the RAS specification. The 
second function is bandwidth management, which is also designated within RAS. For instance, if a 
network manager has specified a threshold for the number of simultaneous conferences on the LAN, the 
Gatekeeper can refuse to make any more connections once the threshold is reached. The effect is to limit 
the total conferencing bandwidth to some fraction of the total available; the remaining capacity is left for 
e-mail, file transfers, and other LAN protocols. The collection of all Terminals, Gateways, and 
Multipoint Control Units managed by a single gatekeeper is known as an H.323 Zone (Figure 4). 

An optional, but valuable feature of a gatekeeper is its ability to route H.323 calls. By routing a call 
through a gatekeeper, it can be controlled more effectively. Service providers need this ability in order to 
bill for calls placed through their network. This service can also be used to re-route a call to another 
endpoint if a called endpoint is unavailable. In addition, a gatekeeper capable of routing H.323 calls can 
help make decisions involving balancing among multiple gateways. For instance, if a call is routed 
through a gatekeeper, that gatekeeper can then re-route the call to one of many gateways based on some 
proprietary routing logic. 

While a Gatekeeper is logically separate from H.323 endpoints, vendors may incorporate Gatekeeper 
functionality into the physical implementation of Gateways and MCUs. 

A Gatekeeper is not required in an H.323 system. However, if a Gatekeeper is present, terminals must 
make use of the services offered by gatekeepers. RAS defines these as address translation, admissions 
control, bandwidth control, and zone management. 

Gatekeepers can also play a role in multipoint connections. To support multipoint conferences, users 
would employ a Gatekeeper to receive H.245 Control Channels from two terminals in a point-to-point 
conference. When the conference switches to multipoint, the Gatekeeper can redirect the H.245 Control 
Channel to a multipoint controller, the MC. The Gatekeeper need not process the H.245 signaling; it 
only needs to pass it between the terminals or the terminals and the MC. 

LANs which contain Gateways could also contain a Gatekeeper to translate incoming E.164 addresses 
into Transport Addresses. Because a Zone is defined by its Gatekeeper, H.323 entities that contain an 
internal Gatekeeper require a mechanism to disable the internal function so that when there are multiple 
H.323 entities that contain a Gatekeeper on a LAN, the entities can be configured into the same Zone. 



Required Gatekeeper Functions 



Address 
Translation 


Translation of alias address to Transport Address using 
a table that is updated with Registration messages. 
Other methods of updating the translation table are also 
allowed. 


Admissions 
Control 


Authorization of LAN access using Admission Request, 
Confirm and Reject (ARQ/ARC/ARJ) messages. LAN 
access may be based on call authorization, bandwidth, 
or some other criteria. Admissions Control may also be 
a null function which admits all requests. 


Bandwidth 


Support for Bandwidth Request, Confirm and Reject 



Control 


(BRQ/BCF/BRJ) messages. This may be based on 
bandwidth management. Bandwidth Control may also 
be a null function which accepts all requests for 
bandwidth changes. 


Zone 

Management 


The Gatekeeper provides the above functions for 
terminals, MCUs, and Gateways which have registered 
within its Zone of control. 



Optional Gatekeeper Functions Include 



Call Control 
Signaling 


In a point to point conference, the Gatekeeper may 
process Q.931 call control signals. Alternatively, the 
Gatekeeper may send the endpoints G.931 signals 
directly to each other. 


Call 

Authorization 


ine vjateKeeper may reject a caii uuiu a icmmiai 
based on the Q.931 specification. The reasons for 
rejection may include, but are not limited to, restricted 
access to/from particular terminals or Gateways, 
restricted access during certain periods of time. The 
criteria for determining if authorization passes or fails 
is outside the scope of H.323. 


Bandwidth 
Management 


The Gatekeeper may reject calls from a terminal if it 
determines that sufficient bandwidth is not available. 
This function also operates during an active call if a 
terminal requests additional bandwidth. The criteria for 
determining if bandwidth is available is outside the 
scope of H.323. 


Call 

Management 


The Gatekeeper may maintain a list of ongoing H.323 
calls in order to indicate that a called terminal is busy 
or to provide information for the Bandwidth 
Management function. 



Multipoint Control Units (MCU) 

The Multipoint Control Unit (MCU) supports conferences between three or more endpoints. Under 
H.323, an MCU consists of a Multipoint Controller (MC), which is required, and zero or more 
Multipoint Processors (MP). The MC handles H.245 negotiations between all terminals to determine 
common capabilities for audio and video processing. The MC also controls conference resources by 
determining which, if any, of the audio and video streams will be multicast. 

The MC does not deal directly with any of the media streams. This is left to the MP, which mixes, 
switches, and processes audio, video, and/or data bits. MC and MP capabilities can exist in a dedicated 
component or be part of other H.323 components. 
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Multipoint Conferences 



Multipoint conference capabilities are handled in a variety of methods and configurations under H.323. 
• The Recommendation uses the concepts of centralized and decentralized conferences, as described in 
Figure 5. 

Centralized multipoint conferences require the existence of an MCU to facilitate a multipoint 
conference. All terminals send audio, video, data, and control streams to the MCU in a point-to-point 
fashion. The MC centrally manages the conference using H.245 control functions that also define the 
capabilities for each terminal. The MP does the audio mixing, data distribution, and video switching/ 
mixing functions typically performed in multipoint conferences and sends the resulting streams back to 
the participating terminals. The MP may also provide conversion between different codecs and bit rates 
and may use multicast to distribute processed video. A typical MCU that supports centralized multipoint 
conferences consists of an MC and an audio, video, and/or data MP. 

Decentralized multipoint conferences can make use of multicast technology. Participating H.323 
terminals multicast audio and video to other participating terminals without sending the data to an MCU. 
Note that control of multipoint data is still centrally processed by the MCU, and H.245 Control Channel 
information is still transmitted in a point-to-point mode to an MC. 

Receiving terminals are responsible for processing the multiple incoming audio and video streams. 
Terminals use H.245 Control Channels to indicate to an MC how many simultaneous video and audio 
streams they can decode. The number of simultaneous capabilities of one terminal does not limit the 
number of video or audio streams which are multicast in a conference. The MP can also provide video 
selection and audio mixing in a decentralized multipoint conference. 

Hybrid multipoint conferences use a combination of centralized and decentralized features. H.245 
signals and either an audio or video stream is processed through point-to-point messages to the MCU. 
The remaining signal (audio or video) is transmitted to participating H.323 terminals through multicast. 

One advantage of centralized conferencing is that all H.323 terminals support point-to-point 
communications. The MCU may output multiple unicasts to the conference participants and no special 
network capabilities are required. Alternatively, the MCU may receive multiple unicasts, mix audio and 
switch video, and output a multicast stream, conserving network bandwidth. 

H.323 also supports mixed multipoint conferences in which some terminals are in a centralized 
conference, others are in a decentralized conference, and an MCU provides the bridge between the two 
types. The terminal is not aware of the mixed nature of the conference, only of the mode of conference 
in which it sends and receives. 

By supporting both multicast and unicast approaches, H.323 spans current generation and future 
networking technologies. Multicast makes more efficient use of network bandwidth, but places higher 
computational loads on the terminals, which have to mix and switch their own audio/video receiving 
streams. Additionally, multicast support is required in network routers and switches. 

An MC may be located within a Gatekeeper, Gateway, Terminal, or MCU. 



Consider a simple example where a multipoint conference is set up between three clients (Figure 6). One 
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client terminal (Client B) performs the MC function. All the terminals could use multicast to participate 
in a decentralized conference. An MP function on each node would mix and present the incoming audio 
and video signals to the user. This approach minimizes the need for specialized network resources. 
However, the network must be configured to support multicast. 

A separate MCU can be used to handle only the audio, data, and control functions. In this configuration 
the video may still be multicast, which conserves bandwidth. This MCU could be either a dedicated 
system or a terminal with extra horsepower. 

Multipoint conferences that span terminals on the LAN and off-network are likely to benefit from 
configurations where the MCU functions are tightly integrated with the Gateway. 



H.323 Version 2 

Approved in January of 1998, version 2 of the H.323 standard addresses deficiencies in version 1 and 
introduces new functionality within existing protocols, such as Q.931, H.245 and H.225, as well as 
entirely new protocols. The most significant advances were in security, fast call setup, supplementary 
services and T.120/H.323 integration. 

Security 

In development for months, the H.235 standard addresses four general issues when dealing with 
security, Authentication, Integrity, Privacy, and non-Repudiation. Authentication is a mechanism to 
make sure that the endpoints participating in the conference are really who they say they are. Integrity 
provides a means to validate that the data within a packet is indeed an unchanged representation of the 
data. Privacy/Confidentiality is provided by encryption and decryption mechanisms that hide the data 
from eavesdroppers so that if it is intercepted, it cannot be viewed. Non-Repudiation is a means of 
protection against someone denying that they participated in a conference when you know they were 
there. 

Fast Call Setup 

Using version one of H.323, a call was placed from one endpoint to another, but streams were not 
immediately available. This resulted in a long delay between the time a call was answered and when the 
participants could hear each other. With H.323 version two and the introduction of Fast Call Setup, this 
problem has been eliminated. 

Supplementary Services 

Supplementary Services for H.323, namely Call Transfer and Call Diversion, have been defined by the 
H.450 series. H.450.1 defines the signaling protocol between H.323 endpoints for the control of 
supplementary services. H.450.2 defines Call Transfer and H.450.3 Call Diversion. Call Transfer allows 
a call established between endpoint A and endpoint B to be transformed into a new call between 
endpoint B and a third endpoint, endpoint C. Call Diversion provides the supplementary services Call 
Forwarding Unconditional, Call Forwarding Busy, Call Forwarding No Reply and Call Deflection. 

T.120/H.323 Integration 

Although the first version of H.323 addressed the integration of T.120 with H.323, the call setup 
scenarios were somewhat complex and unclear. Version 2 of H.323 addresses this problem by requiring 
endpoints that support both T.120 and H.323 to lead the call with H.323. Further, version 2 states that 
T.120 is an optional part of an H.323 conference and that enabling T.120 is at the discretion of each 
H.323 endpoint. 



Communications Under H.323 



Communications under H.323 can be considered a mix of audio, video, data, and control signals. Audio 
capabilities, Q.931 call setup, RAS control, and H.245 signaling are required. All other capabilities, 
including video and data conferencing are optional. When multiple algorithms are possible, the 
algorithms used by the encoder are derived from information passed by the decoder during the H.245 
capability exchange. H.323 terminals are also capable of asymmetric operation (different encode and 
decode algorithms) and can send/receive more than one video and audio channel. 

Control 

The call control functions are the heart of the H.323 terminal. These functions include signaling for call 
setup, capability exchange, signaling of commands and indications, and messages to open and describe 
the content of logical channels. All audio, video, and control signals pass through a control layer that 
formats the data streams into messages for output to the network interface. The reverse process takes 
place for incoming streams. This layer also performs logical framing, sequence numbering, error 
detection, and error correction as appropriate to each media type. The Q.93 1 , RAS, and RTP/RTCP 
protocols perform these functions. 

Overall system control is provided by three separate signaling functions: the H.245 Control Channel, the 
Q.931 Call Signalling Channel, and the RAS Channel. 

The H.245 Control Channel is a reliable channel that carries control messages governing operation of the 
H.323 entity, including capabilities exchange, opening and closing of logical channels, preference 
requests, flow control messages, and general commands and indications. Capabilities exchange is one of 
the fundamental capabilities in the ITU recommendation; H.245 provides for separate receive and 
transmit capabilities as well as for methods to describe these details to other H.323 terminals. There is 
only one H.245 Control Channel per call. 

The Call Signalling Channel uses Q.931 to establish a connection between two terminals. 

The RAS signaling function performs registration, admission, bandwidth changes, status, and disengage 
procedures between endpoints and Gatekeepers. RAS is not used if a Gatekeeper is not present. 

Audio 

Audio signals contain digitized and compressed speech. The compression algorithms supported by 
H.323 are all proven ITU standards. H.323 terminals must support the G.71 1 voice standard for speech 
compression. Support for other ITU voice standards is optional. 

The different ITU recommendations for digitizing and compressing speech signals reflect different 
tradeoffs between speech quality, bit rate, computer power, and signal delay. G.71 1 generally transmits 
voice at 56 or 64 kbps, well within the bandwidth limits likely on a LAN, but was designed originally 
for continuous bit-rate networks. Because G.723 operates at very low bit rates, it is strongly being 
considered as a required codec and will be the predominant audio codec in H.323 applications. 

Video 

While video capabilities are optional, any video-enabled H.323 terminal must support the H.261 codec; 
support for H.263 is optional. Video information is transmitted at a rate no greater than that selected 
during the capability exchange. H.261, which provides a measure of compatibility across many of the 
different ITU recommendations (see table on next page), is used with communication channels that are 
multiples of 64 kbps (P=l,2,3...30). H.261 calls for fully encoding some frames and for coding only the 



difference between a frame and the previous frame in other cases. Motion compensation, which 
• improves image quality, is an H.261 option. 



H 263 is a backwards-compatible update to H.261. H.263 picture quality is greatly improved by using a 
required 1/2 pixel motion-estimation technique, predicted frames, and a Huffman coding table optimized 
for low bit rate transmissions. H.263 defines five standardized picture formats. Communications 
between H.261 systems and H.263 systems is facilitated because both must support QCIF. 



Videoconferencing 
Picture Format 


Image Size 
In Pixels 


H.261 


H.263 


sub-QCIF 


128x96 


not specified 


required 


QCIF 


176x144 


required 


required 


CIF 


352x288 


optional 


optional 


4CIF 


704x576 


N/A 


optional 


16CIF 


1408x1152 


N/A 


optional 



ITU Formats for videoconferencing 



Data 



Data conferencing is an optional capability. When supported, data conferencing enables collaboration 
through applications such as shared whiteboards, application sharing, and file transfer. 

H 323 supports data conferencing through the T.120 specification (Figure 7). An ITU standard, T.120 
addresses point-to-point and multipoint data conferences. It provides interoperability at the application, 
network, and transport level. 

An H.323 system can support data by incorporating T.120 capabilities into clients and multipoint control 
units. The MCU may control and mix the data conferencing information. 

A recommendation for multicast support in T.120, known as T.125 Annex A or the Multicast Adaptation 
Protocol, was approved by the ITU in January of 1998 

(A primer on the T.120 series standard is available.) 
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figure 7 
Click for larger version 



IP Networking and Multimedia Conferencing 

H.323 uses both reliable and unreliable communications. Control signals and data require reliable 
transport because the signals must be received in the order in which they were sent and cannot be lost. 
Audio and video streams lose their value with time. If a packet is delayed, it may not have relevance to 
the end user. Audio and video signals use the more efficient unreliable transport. 



Reliable transmission of messages uses a connection-oriented mode for data transmission. In the IP 
stack this type of transmission is accomplished with TCP. Reliable transmission guarantees sequenced, 
error-free flow-controlled transmission of packets, but can delay transmission and reduce throughput. 
H.323 uses reliable (TCP) end-to-end services for the H.245 Control Channel, the T.120 Data Channels, 
and the Call Signaling Channel. 

Within the IP stack, unreliable services are provided by User Datagram Protocol (UDP). Unreliable 
transmission is a mode without connections that promises nothing more than "best effort" delivery. UDP 
offers minimal control information. H.323 uses UDP for the audio, video, and the RAS Channel. 

In conferences with multiple audio and video streams, unreliable transport via UDP uses IP Multicast 
and the Real-Time Protocol (RTP) developed by the Internet Engineering Task Force (IETF) to handle 
streaming audio and video. IP Multicast is a protocol for unreliable multicast transmission m UDP. RTP 
works on top of IP Multicast, and was designed to handle the requirements of streaming audio and video 
over the Internet. A header containing a time-stamp and a sequence number is added to each UDP 
packet. With appropriate buffering at the receiving station, timing and sequence information allows the 
application to eliminate duplicate packets; reorder out-of-sequence packets; synchronize sound, video 
and data; and achieve continuous playback in spite of varying latencies. 

Because H.323 is RTP-based, it can operate on the Internet's Multicast Backbone (Mbone), a virtual 
network on top of the Internet that provides a multicast facility and supports video, voice, and data 
conferencing. The Real-Time Control Protocol (RTCP) is used for the control of RTP. RTCP monitors 
the quality of service, conveys information about the session participants, and periodically distributes 
control packets containing quality information to all session participants through the same distribution 
mechanisms as the data packets. 

Having sufficient bandwidth for a multimedia call is critical and difficult to ensure in large packet 
networks like the Internet or a corporate intranet. Another IETF protocol, the Resource Reservation 
Protocol (RSVP), allows a receiver to request a specific amount of bandwidth for a particular data 
stream and receive a reply indicating whether the request has been granted. Although RSVP is not an 
official part of the H.323 standard, some H.323 products will support it. RTP needs to be supported by 
Terminals, Gateways, and MCUs with Multipoint Processors. RSVP may also be supported by the same 
components and any intermediate switches or routers. 
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Overview of ITU Videoconferencing Standards 

H 323 is the newest member of a family of ITU umbrella recommendations that cover videotelephony 
and multimedia communications over a variety of pipelines. H.323 is in many ways a derivative of 
H 320, a 1990 umbrella recommendation for video telephony over switched digital telephone networks. 
H 323 borrows heavily from H.320's structure, modularity, and audio/video codec recommendations. 



Interoperability 

In the past few years, interoperability testing has come to the forefront of the conferencing industry. 
Sponsored by the IMTC and dozens of individual hardware and software companies, interoperability 
testing enables developers to test their H.32x- and T.120- compliant products with others. 

While the ITU's role is that of a standards-setting body, the IMTC focuses on the practical validation 
and promotion of standards. The IMTC's emphasis is on multimedia tele-conferencing, including still- 
image graphics, full-motion video, and data teleconferencing. The IMTC focused on ensuring the 
adoption of the required standards and education of the market. 

IMTC-organized events are intended to facilitate the rapid development and delivery of standards-based 
conferencing products and services and to continue promoting the importance of industry-wide 
interoperability as a base for building consumer confidence. To date, the interoperability tests have 
centered on H.324 and T.120 testing. H.323 interoperability tests began in 1996 and will contmue 
through the coming years. Testing is likely to extend over a protracted period of time as multiple 
vendors cooperate to test a multi-dimensional matrix of equipment, networks, codecs, and protocols. 



Implementing H.323 

With H 323 standards beginning to take root in the market, equipment vendors and software providers 
face the challenge of implementing the complex H.323 standard. DataBeam provides developers with a 
set of software toolkits and development platforms to implement all or a portion of the H.323 standard. 
These toolkits will enable vendors to select the functionality they need to complement their product and 
ensure that it will work with other vendor products. DataBeam is committed to interoperability with all 
other H.323-compliant vendors. 

DataBeam has made a significant research and development investment in the development of H.323 
technology. The code is field-tested and proven in product implementations. 

Continued maintenance and updates to the technology will be available through DataBeam. DataBeam i 
an active participant in standards bodies and tracks changes to the H.323 specification. 

DataBeam's experience and expertise in OEM licensing ensures that customers receive the highest 
quality service and support. DataBeam is committed to providing H.323 developers comprehensive 
development solutions for the fastest route to market. 



Key H.323 Terms 

Call: Point-to-point multimedia communication between two H.323 endpoints. 

Call Signaling Channel: Reliable channel used to convey call setup messages following Q.931. 

Centralized Multipoint Conference: A call in which all participating terminals communicate in a 
point-to-point fashion with an MCU. 

Common Intermediate Format (CIF): Image format for H.263. Represents 352 pixels/line by 288 
lines/image. 

Decentralized Multipoint Conference: A conference in which the participating terminals multicast to 
all other participating terminals without an MCU. 

E.164: Address format for ISDN networks. See ITU Recommendation E.164 (1991). 
Endpoint: A Terminal, Gateway, or MCU. 

Gatekeeper (GK): An H.323 entity that provides address translation, control access, and sometimes 
bandwidth management to the LAN for H.323 terminals, Gateways, and MCUs. 

Gateway (GWV An H.323 entity which provides real-time, two-way communications between H.323 
terminals on the LAN and other ITU terminals on a WAN, or to another H.323 Gateway. 

H.323 Entity: Any H.323 component, including terminals, Gateways, Gatekeepers, MCs, MPs, and 
MCUs. 

H.245 Logical Channel: A channel carrying information streams between two H.323 endpoints. 
IP: Internet Protocol 

Local Area Network: A shared or switched medium, peer-to-peer communications network which may 
include inter-networks composed of LANs connected by bridges or routers. 

Multicast: A process of transmitting from one source to many destinations. The actual mechanism may 
be different for different LAN technologies. 

Multipoint Conference: A conference between three or more terminals, which may be on the LAN or 
on the Circuit Switched Network. 

Multipoint Control Unit (MCU): An endpoint on the LAN which enables three or more terminals and 
Gateways to participate in a multipoint conference. The MCU includes a mandatory Multipoint 
Controller and optional Multipoint Processors. 

Multipoint Controller (MC): An entity which provides for the control of three or more terminals in a 
multipoint conference. 

Multipoint Processor (MP): An entity which provides for the processing of audio, video, and/or data 
streams in a multipoint conference. The MP provides for the mixing, switching, or other processmg of 
media streams under the control of the MC. 

Quality of Service (QoS): Guarantees network bandwidth and availability for applications. 



Q.93U: Call signaling protocol for setup and termination of calls. 

RAS Channel: An unreliable channel used to convey the Registration, Admissions and Status messages 
and bandwidth changes between two H.323 entities. 

Reliable Transmission: Connection-oriented data transmission which guarantees sequenced, error-free, 
flow-controlled transmission of messages to the receiver. 

Resource Reservation Protocol (RSVP): IETF specification. Allows applications to request dedicated 
bandwidth. 

Real-Time Protocol/Real-Time Control Protocol (RTP/RTCP): IETF specification for audio and 
video signal management. Allows applications to synchronize and spoil audio and video information. 

Switched Circuit Network (SCN): A public or private switched telecommunications network such as 
GSTN or ISDN. 

TCP: Transmission control protocol. A reliable networking layer on top of IP. 

Terminal: An endpoint which provides for real-time, two-way communications with another Terminal, 
Gateway, or MCU. A terminal must provide audio and may also provide video and/or data. 

UDP: User Datagram Protocol. An unreliable networking layer which sits at the same level of the 
networking stack as TCP. 

Unreliable Transmission: Connection-less transmission which provides best-effort delivery of data 
packets. Messages transmitted by the sender may be lost, duplicated, or received out of sequence. 

Zone: A collection of all Terminals, Gateways, and MCUs managed by a single Gatekeeper. A zone 
must include at least one Terminal and may include LAN segments connected using routers. 
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